Shall we link an issue or comment describing this problem in more detail?

I linked to rust-lang/rust#132203

Thank you for doing your due diligence to look up the actual upstream issue. I'll comment there later because it doesn't seem to be explicitly mentioned that this "regression" has trickled into 1.83 - i.e. they didn't fix / back it out before the release.

At the same time I hate to call this a regression, it's a good change. As outlined in #127 (comment) already, I feel like having the path relative to README.md (i.e. the span of that file) is much more sensible than having it relative to whichever random file (or files, it could be multiple in different locations) is/are including README.md.
But that requires a breaking change...

EDIT: upstream Rust issues and pull requests are incredibly poorly documented. They all reference each other, but none of them have an accurate summary describing what they're observing or changing, requiring one to follow links all the way to the beginning, then unwind again to understand what is going on:

1. Span in rustdoc errors is incorrectly reported for include_str!(): rustdoc reports issues against lib.rs rather than an include_str!'d file rust-lang/rust#130470
2. Fix for that: rustdoc: use the correct span for doctests rust-lang/rust#130582
3. That fix regresses recursive imports: regression: change in paths/CWD for rustdoc tests rust-lang/rust#132203
   • Regression in Rust 1.83: Change in resolution of relative paths in doctest included with #[doc = include_str(...)] in 1.83.0 rust-lang/rust#133824
4. Fixing regression by making it an edition 2024 change: rustdoc: make doctest span tweak a 2024 edition change rust-lang/rust#132210
5. Decision to change such behaviour must have a tracking issue etc: Tracking issue for Rust 2024: Fix doctest include paths rust-lang/rust#132230
   (Notice my frustration again: this spends more words explaining what a tracking issue is, than describing what it is tracking beyond "fixing the path used for include in rustdoc doctests")